System and method of payment of merchants on behalf of payment card system transaction acquirers

ABSTRACT

Methods and systems for handling a payment card account system transaction. In an embodiment, a merchant payment services computer receives merchant bank account details for at least one merchant supported by an acquirer financial institution and stores the merchant bank account details in a storage device. The process also includes the merchant payment services computer receiving, from a card payment network computer, card account transaction information for a merchant over a predetermined period of time; calculating, based on the card account transaction information, a net position for the merchant; retrieving merchant bank account details of the merchant from the storage device; and initiating an electronic funds transfer (EFT) with an originating payment services provider (PSP) computer of an electronic funds transfer system to credit the merchant&#39;s deposit account in an amount equal to the merchant&#39;s net position.

CROSS REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of U.S. patent application Ser. No.15/621,327 filed on Jun. 13, 2017, and of U.S. Provisional PatentApplication Nos. 62/350,322 filed Jun. 15, 2016; 62/350,335 filed Jun.15, 2016; 62/350,407 filed Jun. 15, 2016; 62/351,155 filed Jun. 16,2016; 62/350,821 filed Jun. 16, 2016; 62/351,016 filed Jun. 16, 2016;62/351,227 filed Jun. 16, 2016; 62/350,831 filed Jun. 16, 2016;62/350,416 filed Jun. 15, 2016; and 62/351,164 filed Jun. 16, 2016; thecontents of which patent application and provisional patent applicationsare hereby incorporated by reference for all purposes.

BACKGROUND

In the “four party model” upon which most payment card systems arebased, merchants that accept payment card transactions do so viaagreements with transaction acquirers. Transaction acquirers aretypically financial institutions authorized to act as intermediariesbetween merchants and the financial institutions that issue paymentcards. Among the systems that employ the four party model areMasterCard, Visa, RuPay and Union Pay. Acquirers typically make paymentsto merchants using conventional EFT payment network rails and depositfunds to merchants' bank accounts based on the net settlement positionsthat the merchants have with the acquirer after netting fees and theapplicable merchant discount rate (MDR). Set up of such payments iscomplex, and it is common for merchants to receive payment three daysafter a payment card transaction occurs.

The present inventors have now recognized opportunities to improvehandling of payments to merchants with respect to payment cardtransactions.

BRIEF DESCRIPTION OF THE DRAWINGS

Features and advantages of some embodiments of the present disclosure,and the manner in which the same are accomplished, will become morereadily apparent upon consideration of the following detaileddescription of the invention taken in conjunction with the accompanyingdrawings, which illustrate preferred and example embodiments and whichare not necessarily drawn to scale, wherein:

FIG. 1 is a block diagram of a payment card account system.

FIG. 2 is block diagram of a payment system such as an EFT (electronicfunds transfer) system.

FIG. 3 is a block diagram of a payment card system provided inaccordance with aspects of the present disclosure.

FIG. 4 is a block diagram of an example computer system that may performfunctions in the system of FIG. 3 .

FIGS. 5, 6, 7 and 8 are flow charts that illustrate processes that maybe performed in the system of FIG. 3 in accordance with aspects of thepresent disclosure.

DESCRIPTION

In general, and for the purpose of introducing concepts of embodimentsof the present disclosure, an EFT payment network in conjunction with apayment card system may be enabled to provide an integrated merchantpayment solution for acquirers. The card system operator may provide anautomated payment function that allows automated calculation ofsettlements due to merchants and immediate implementation of creditingor debiting the merchant's bank account using the EFT payment network.

Merchants may be enrolled in the automated system, from the acquirer'spoint of view, via bulk data loads to the payment card system operator.In addition or alternatively, the payment card system operator may hosta self-serve portal that allows merchants to provide or update theirbank account details. The automated system may also implement backoffice automation that executes payments when due based on triggersdefined by the acquirer.

Such an automated system for paying merchants may shorten the timebetween execution of the card transaction and payment to merchant, thusimproving the cash flows for merchants. Moreover, administrative burdenson acquirers may be reduced and acquirers may be enabled to providebetter service to the merchants they support.

FIG. 1 is a block diagram that illustrates a payment card account system100.

The system 100 includes a customer device 102 such as a magnetic stripecard, a payment IC (integrated circuit) card (contactless and/orcontact), or a payment-enabled mobile device. Block 104 in FIG. 1represents a merchant device such as a POS (point of sale) terminal/cardreader. The merchant device 104 may also be considered part of thepayment card account system 100. The customer device 102 may bepresented to the merchant device 104, to consummate a purchasetransaction and to permit the merchant device 104 to read payment cardaccount data (including, e.g., a payment account number) from thecustomer device 102. In other situations, the merchant device 104 may bean e-commerce server computer, and the customer device 102 may be apersonal computer, a mobile device running a mobile browser, etc.; insuch situations, the customer device 102 may engage in an onlineshopping session with an e-commerce website hosted by the merchantdevice 104.

A computer 106 operated by an acquirer (acquiring financial institution)is also shown as part of the system 100 in FIG. 1 . The acquirercomputer 106 may receive a payment account system authorization requestmessage for the transaction from the merchant device 104. The acquirercomputer 106 may route the authorization request message via a cardnetwork 108 to a server computer 110 operated by the issuer of a paymentaccount that is associated with the account number obtained by themerchant device 104 (e.g., from the customer device 102) and included inthe authorization request message. The authorization response messagegenerated by the payment issuer server computer 110 may be routed backto the merchant device 104 via the card network 108 and the acquirercomputer 106.

One well known example of a card network is referred to as the “Banknet”system, and is operated by Mastercard International Incorporated, whichis the assignee hereof.

The payment account issuer server computer 110 may be operated by or onbehalf of a financial institution (“FI”) that issues payment accounts toindividual users such as the customer who presented or operated thecustomer device 102 referred to above. For example, the payment cardissuer server computer 110 may perform such functions as (a) receivingand responding to requests for authorization of payment accounttransactions to be charged to payment accounts issued by the FI; and (b)tracking and storing transactions and maintaining account records.

The payment card account system communications among the merchants,acquirers, card network and/or issuers may conform to a known standardsuch as ISO 8583.

The components of the system 100 as depicted in FIG. 1 are only thosethat are needed for processing a single transaction. A typical paymentsystem may process many purchase transactions (including simultaneoustransactions) and may include a considerable number of payment accountissuers and their computers, a considerable number of acquirers andtheir computers, and numerous merchants and their devices, as well as avery large number of customer devices.

FIG. 2 is a block diagram that illustrates a payment network system 200,of which one example is the ACH (automated clearing house) systemoperated in the United States.

The system 200 includes an originator device 202, which may be acomputer operated by an originator of a transaction. Common kinds oftransactions are credit transactions and debit transactions. Theoriginator is the party that initiates the transaction. The originatormay be, for example, an individual or a corporation or otherorganization.

The system 200 further includes an originator PSP (payment servicesprovider) computer 204. The originator PSP computer 204 receives paymentinstructions from the originator and forwards data entries that reflectthe instructions to a payment system switch/network 206, which is alsopart of the system 200. The originator PSP computer 204 may be operatedby an originator PSP of which the originator is a customer. Theswitch/network 206 may be operated by a governmental or private entitythat serves as a clearing facility for the system 200.

Also included in the system 200 is a beneficiary PSP computer 208. Thebeneficiary PSP computer 208 receives entries from the payment systemswitch/network 206 and posts entries to accounts of depositors.

Still further, the system 200 includes a beneficiary 210 that is one ofthe depositors of the beneficiary PSP. In the case of a credittransaction, the account at the beneficiary PSP of the beneficiary maybe credited with the amount instructed to be paid by the originatordevice 202. The beneficiary may be, for example, an individual or acorporation or other organization. Both PSPs may typically be banks orother financial institutions (FIs).

The communications among the parties in the system 200 may typically beconducted using XML (eXtensible Markup Language) and may comply with astandard according to ISO 20022.

The components of the system 200 as depicted in FIG. 2 are only thosethat are needed for processing a single transaction. A typical paymentnetwork system may process many transactions (including simultaneoustransactions) and may include a considerable number of PSPs and theircomputers, one or more clearing operators, and numerous originators andbeneficiaries

FIG. 3 is a block diagram of a payment card system 300 provided inaccordance with aspects of the present disclosure.

The payment card system 300 may include all the components describedabove in connection with FIG. 1 , including a customer device 102, amerchant device or system (labeled with reference numeral 104 a toreflect additional functionality it may provide in the system 300), atransaction acquirer (labeled with reference numeral 106 a to reflectadditional functionality it may provide in the system 300), a cardnetwork (labeled with reference numeral 108 a to reflect additionalfunctionality it may provide in the system 300), and a payment cardissuer 110.

Further, the payment card system 300 may include a merchant paymentservices computer 302. The merchant payment services computer 302 may bein communication with the card network 108 a, and may be under commonoperation with the card network 108 a. In some embodiments, hardwaremaking up the merchant payment services computer 302 may at leastpartially overlap with one or more computer systems that implement thecard network 108 a. Details of the merchant payment services computer302 will be described below. In general, the merchant payment servicescomputer 302 may receive and store merchants' deposit account details,and may manage execution of payments due from acquirers to merchants.For embodiments in which the merchant payment services computer 302 isunder common operation with the card network 108 a, or at leastpartially overlaps therewith in hardware terms, actions ascribed hereinto the merchant payment services computer 302 may also be deemed to havebeen performed by the card network 108 a.

The payment card system 300 is further shown as incorporating anoriginator payment services provider (O-PSP) 304. The O-PSP may resembleitem 204 described above in connection with FIG. 2 and may be incommunication with the merchant payment services computer 302.

In addition, the payment card system 300 may include or be in acooperative relationship with a payment switch/network 306, which mayresemble item 206 described above in connection with FIG. 2 . Thepayment switch/network 306 may be in communication with the O-PSP 304.

Still further, the payment card system 300 is shown as incorporating abeneficiary payment services provider (B-PSP) 308. The B-PSP 308 mayresemble item 208 described above in connection with FIG. 2 . The B-PSP308 may be in communication with the payment switch/network 306.

Communication channels or possible communication channels are also shownfrom the acquirer 106 a and the merchant system 104 a, respectively, tothe merchant payment services computer 302.

The components 304, 306, 308 shown in FIG. 3 may be part of an EFTsystem such as an ACH system.

Any one or more of the blocks shown in FIG. 3 , in addition torepresenting the indicated entity, may also be considered to representone or more computer systems operated by such entity.

FIG. 4 is a block diagram of an example embodiment of the merchantpayment services computer 302.

Referring now to FIG. 4 , the merchant payment services computer 302may, in its hardware aspects, resemble a typical server computer and/ormainframe computer, but may be controlled by software to cause it tofunction as described herein.

The merchant payment services computer 302 may include a computerprocessor 400 operatively coupled to a communication device 401, astorage device 404, an input device 406 and an output device 408. Thecommunication device 401, the storage device 404, the input device 406and the output device 408 may all be in communication with the processor400.

The computer processor 400 may be constituted by one or more processors.Processor 400 operates to execute processor-executable steps, containedin program instructions described below, so as to control the merchantpayment services computer 302 to provide desired functionality.

Communication device 401 may be used to facilitate communication with,for example, other devices (such as other components of the paymentsystem 300, including the card network 108 a, the O-PSP 308, theacquirer 106 a and/or the merchant system 104 a). Communication device401 may comprise numerous communication ports (not separately shown), toallow the merchant payment services computer 302 to communicatesimultaneously with a number of other computers and other devices,including communications as required to simultaneously handle numerousinteractions with other devices.

Input device 406 may comprise one or more of any type of peripheraldevice typically used to input data into a computer. For example, theinput device 406 may include a keyboard and a mouse. Output device 408may comprise, for example, a display and/or a printer.

Storage device 404 may comprise any appropriate information storagedevice, including combinations of magnetic storage devices (e.g., harddisk drives), optical storage devices such as CDs and/or DVDs, and/orsemiconductor memory devices such as Random Access Memory (RAM) devicesand Read Only Memory (ROM) devices, as well as so-called flash memory.Any one or more of such information storage devices may be considered tobe a computer-readable storage medium or a computer usable medium or amemory.

Storage device 404 stores one or more programs for controlling processor400. The programs comprise program instructions (which may be referredto as computer readable program code means) that containprocessor-executable process steps of the merchant payment servicescomputer 302, executed by the processor 400 to cause the merchantpayment services computer 302 to function as described herein.

The programs may include one or more conventional operating systems (notshown) that control the processor 400 so as to manage and coordinateactivities and sharing of resources in the merchant payment servicescomputer 302, and to serve as a host for application programs (describedbelow) that run on the merchant payment services computer 302.

The programs stored in the storage device 404 may include, for example,an application program 410 for providing one or more software interfacesto allow the merchant payment services computer 302 to receive inputthat provides details of merchant bank accounts.

Another program that may be stored in the storage device 404 is a webhosting application program 412 for enabling the merchant paymentservices computer 302 to host one or more web portals that areaccessible by merchants and/or acquirers to allow them to enter orupdate merchant bank account details.

The storage device 404 may also store an application program 414 thatprograms the processor 400 to enable the merchant payment servicescomputer 302 to manage payments to merchants on behalf of transactionacquirers. Details of the merchant payment application program 414 willbe described below.

The storage device 404 may further store one or more software modules(block 416) that serve as software interfaces between the merchantpayment services computer 302 and one or more O-PSPs that areconstituents of the above discussed EFT system.

The storage device 404 may also store, and the merchant payment servicescomputer 302 may also execute, other programs, which are not shown. Forexample, such programs may include communications software and areporting application. The latter program may respond to requests fromsystem administrators for reports on the activities performed by themerchant payment services computer 302. The other programs may alsoinclude, e.g., device drivers, database management software, etc.

Still further, the storage device 404 may store a database 418 thatstores merchant bank account details that have been uploaded to themerchant payment services computer 302. The storage device 404 may alsostore one or more other databases 420 needed for operation of themerchant payment services computer 302.

Other computerized components of the system 300 may be constituted bycomputer hardware having the same type of components and hardwarearchitecture as described herein with reference to FIG. 4 .

FIG. 5 is a flow chart that illustrates a process that may be performedin the system of FIG. 3 in accordance with aspects of the presentdisclosure.

At 502 in FIG. 5 , the merchant payment services computer 302 receivesthe merchant bank account details. In some embodiments, there may bethree or more ways in which the merchant bank account details arereceived by the merchant payment services computer 302. These mayinclude, for example: (a) the acquirer sending to the merchant paymentservices computer 302 a batch file containing merchant bank accountdetails for a number of merchants supported by the acquirer; (b)uploading of merchant bank account detail by the acquirer to themerchant payment services computer 302 via a direct API; (c) merchantinteraction with a merchant self-serve portal, as referred to above; and(d) one or more portals available for use by acquirer support personnel.Such portals may be made available by one or more of (i) a web serviceAPI that interacts with the acquiring system; (ii) a web portal foraccess by customer support staff from the acquirer's perspective; and(iii) a portal hosted by the merchant payment services computer 302 foraccess by merchants. The latter portal may serve as a “one stop shop” toallow the merchants to access acquiring services such that the merchantsmay make relevant changes to their payment bank account details and toaccess reports providing payment schedules and payment history for agiven merchant's records.

The latter portal may also provide merchant registration by merchantsdirectly and also access to acquirer support staff to enter details.FIG. 6 is a flow chart that illustrates an embodiment of such a process.At 602 in FIG. 6 , the merchant/merchant staff member may enter thenecessary data to identify the merchant and the merchant's bank accountinformation. At 604 in FIG. 6 , communication may occur between themerchant payment services computer 302 and the merchant/merchant staffmember to satisfy “know your customer” compliance requirements. This mayinvolve submission of suitable documentation (e.g., scanned facsimilesof documents) by the merchant and review of the same by systememployees.

At 606 in FIG. 6 , the merchant payment services computer 302 may engagein suitable ID&V (identification and verification) processes to assureauthentication of the merchant engaging in the registration. (A similarID&V process may occur when the merchant updates its registration data.)

At 608, the merchant payment services computer 302 may confirm to themerchant that the registration process is complete.

When the merchant-related data is uploaded by the acquirers, theuploaded data may include such relevant information as bank accountdetails (bank, routing number and bank account number), MDR, servicefees, and frequency of payments.

Referring again to FIG. 5 , at 504, the merchant payment servicescomputer 302 stores the merchant bank account details and other datauploaded by the acquirers and/or merchants.

As indicated at 506, further processing may occur at a later time afterthe merchant bank account details are received and stored by themerchant payment services computer 302. At the later time, the merchantpayment services computer 302 may manage payments to merchants (block508, FIG. 5 ) in regard to payment card account transactions involvingthe merchants. In doing so, the payments may be based on informationcollected by and made available from the card network 108 a (FIG. 3 ).The card network 108 a may have all the transaction details from themerchants and the acquirers and thus may enable the merchant paymentservices computer 302 to be informed of the merchants' net positions andto make payments accordingly directly to the merchants on behalf of theacquirers.

FIG. 7 is a flow chart that illustrates details of the processing thatmay occur at 506.

At 702 in FIG. 7 , the merchant payment services computer 302 mayreceive card account transaction information for the merchant over aperiod of time (say, one day).

At 704, the merchant payment services computer 302 may apply the “MDR”(merchant discount rate) that is in effect between the merchant and themerchant's acquiring financial institution.

At 706, the merchant payment services computer 302 may calculate themerchant's net position vis a vis the acquirer, taking the MDR and anycurrent charge-back transactions into account.

At 708, the merchant payment services computer 302 may initiate an EFTtransaction to transfer—to the merchant—the merchant's net balance owedfrom the acquirer. This transaction may be a credit push payment via anEFT system, as represented by blocks 304, 306 and 308 in FIG. 3 .

In various embodiments, or various situations, for a given merchant, theEFT transaction referred to at 708 may occur daily, or at regular timesmore frequently than daily, or in response to each payment card accountsystem transaction that is accepted by the merchant and authorized bythe account issuer, or each time a threshold balance due to the merchantis reached, or less frequently than daily; or some combination of theforegoing.

In some embodiments, the merchant payment services computer 302 may keepa running total of the amount due to the merchant from the acquirer. Incases where the funds transfer to the merchant is triggered by reachinga positive balance threshold, the acquirer may have set the threshold inaccordance with its service agreement with the merchant and as part ofthe merchant registration performed by the acquirer.

In situations where the merchant is the debtor, then the merchant may beprovided an opportunity through the merchant self-serve portal toinitiate a push payment transaction to the acquirer to settle themerchant's obligation to the acquirer. FIG. 8 is a flow chart thatillustrates a process whereby a merchant settles an obligation to theacquirer.

At decision block 802 in FIG. 8 , the merchant payment services computer302 determines whether the merchant's net position is such that themerchant owes money to the acquirer. If a positive determination is madeat decision block 802, then block 804 may follow decision block 802. (Inthe absence of a positive determination at decision block 802, theprocess of FIG. 8 may end.) At block 804, the merchant payment servicescomputer 302 may send a message such as a text message or an emailmessage to the merchant to advise the merchant that the merchant has anegative balance vis a vis the acquirer.

A decision block 806 may follow block 804. At decision block 806, themerchant payment services computer 302 may determine whether themerchant has requested that a transfer occur to settle the merchant'sobligation to the acquirer. If so, then block 808 may follow decisionblock 806. (In the absence of a positive determination at decision block806, the process of FIG. 8 may end.) At 808, the merchant paymentservices computer 302 may initiate an EFT transfer charged to themerchant's account and to benefit the acquirer in order to settle themerchant's obligation.

An arrangement as described with reference to FIGS. 3-8 may simplifymanagement of merchants by acquirers and at the same time may providemerchants with quick access to cash at their bank deposit accounts inrespect to payment card account system transactions accepted by themerchant.

As used herein and in the appended claims, the term “computer” should beunderstood to encompass a single computer or two or more computers incommunication with each other.

As used herein and in the appended claims, the term “processor” shouldbe understood to encompass a single processor or two or more processorsin communication with each other.

As used herein and in the appended claims, the term “memory” should beunderstood to encompass a single memory or storage device or two or morememories or storage devices.

As used herein and in the appended claims, a “server” includes acomputer device or system that responds to numerous requests for servicefrom other devices.

The above descriptions and illustrations of processes herein should notbe considered to imply a fixed order for performing the process steps.Rather, the process steps may be performed in any order that ispracticable, including simultaneous performance of at least some steps.

As used herein and in the appended claims, the term “payment card systemaccount” includes a credit card account, a deposit account that theaccount holder may access using a debit card, a prepaid card account, orany other type of account from which payment transactions may beconsummated. The terms “payment card system account” and “payment cardaccount” and “payment account” are used interchangeably herein. The term“payment card account number” includes a number that identifies apayment card system account or a number carried by a payment card, or anumber that is used to route a transaction in a payment system thathandles payment card transactions. The term “payment card” includes acredit card, debit card, prepaid card, or other type of paymentinstrument, whether an actual physical card, electronic, or virtual.

As used herein and in the appended claims, the term “payment cardsystem” or “payment account system” refers to a system for handlingpurchase transactions and related transactions. An example of such asystem is the one operated by MasterCard International Incorporated, theassignee of the present disclosure. In some embodiments, the term“payment card system” may be limited to systems in which memberfinancial institutions issue payment card accounts to individuals,businesses and/or other organizations.

Although the present invention has been described in connection withspecific example embodiments, it should be understood that variouschanges, substitutions, and alterations apparent to those skilled in theart can be made to the disclosed embodiments without departing from thespirit and scope of the invention as set forth in the appended claims.

What is claimed is:
 1. An integrated merchant payment method comprising:receiving, by a merchant payment services computer, merchant bankaccount details for at least one merchant supported by an acquirerfinancial institution; storing, by the merchant payment servicescomputer, the merchant bank account details in a storage device;receiving, by the merchant payment services computer from a card paymentnetwork computer, card account transaction information for a merchantover a predetermined period of time; calculating, by the merchantservices computer based on the card account transaction information, anet position for the merchant; retrieving, by the merchant servicescomputer from the storage device, merchant bank account details of themerchant including the merchant's deposit account; and initiating, bythe merchant payment services computer, an electronic funds transfer(EFT) with an originating payment services provider (PSP) computer of anelectronic funds transfer system to credit the merchant's depositaccount in an amount equal to the merchant's net position.
 2. The methodof claim 1 wherein receiving merchant bank account details comprisesreceiving, from an acquirer computer, a batch file containing merchantbank account details for a plurality of merchants.
 3. The method ofclaim 1 wherein receiving the merchant bank account details comprisesreceiving, by the merchant payment services computer from an acquirercomputer, merchant bank account details via a direct API.
 4. The methodof claim 1 wherein receiving the merchant bank account details comprisesreceiving, by the merchant services computer, the merchant bank accountdetails directly from one of a merchant self-service portal or anacquirer support personnel portal.
 5. The method of claim 1 furthercomprising, after receiving the card account transaction information forthe merchant: applying, by the merchant payment services computer, amerchant discount rate (MDR) to the card account transactioninformation; and calculating, by the merchant services computer afterapplication of the MDR, the merchant's net position.
 6. The method ofclaim 5 wherein calculating the merchant's net position furthercomprises including an amount equal to current charge-back transactions.7. The method of claim 1 further comprising: determining, by themerchant payment services computer from the net position of themerchant, that the merchant owes money to the acquirer financialinstitution; transmitting, by the merchant payment services computer toa merchant device, a message indicating a negative balance vis a vis theacquirer financial institution; receiving, by the merchant paymentservices computer from the merchant device, a request to transfer fundsto the acquirer financial institution in an amount to satisfy thenegative balance; and initiating, by the merchant payment servicescomputer, an EFT with the originating PSP computer of the electronicfunds transfer system to credit an acquirer account of the acquirerfinancial institution in the amount to satisfy the negative balance. 8.The method of claim 1 wherein the EFT is an automated clearing house(ACH) system.
 9. An integrated payment card system comprising: amerchant payment services computer comprising a processor operablyconnected to a communication device and to a storage device; a paymentcard network computer operably connected to the merchant paymentservices computer; and an electronic funds transfer (EFT) systemcomprising an originating payment services provider (PSP) computeroperably connected to the merchant payment services computer; whereinthe storage device of the merchant payment services computer storesprocessor executable instructions which when executed cause theprocessor of the merchant payment services computer to: receive merchantbank account details for at least one merchant supported by an acquirerfinancial institution; store the merchant bank account details in thestorage device; receive, from the payment card network computer, cardaccount transaction information for a merchant over a predeterminedperiod of time; calculate, based on the card account transactioninformation, the merchant's net position; retrieve merchant bank accountdetails of the merchant including the merchant's deposit accountinformation from the storage device; and initiate an electronic fundstransfer with the originating PSP computer of the EFT system to creditthe merchant's deposit account based on the merchant deposit accountinformation in an amount equal to the merchant's net position.
 10. Theintegrated payment card system of claim 9 further comprising an acquirercomputer operably connected to the merchant payment services computer,wherein merchant bank account details are received from the acquirercomputer in a batch file containing the merchant bank account detailsfor a plurality of merchants.
 11. The integrated payment card system ofclaim 9 further comprising an acquirer computer operably connected tothe merchant payment services computer, wherein the merchant bankaccount details are received from the acquirer computer via a directAPI.
 12. The integrated payment card system of claim 9 wherein themerchant bank account details are received directly from one of amerchant self-service portal or an acquirer support personnel portal.13. The integrated payment card system of claim 9 wherein the storagedevice of the merchant payment services computer stores furtherprocessor executable instructions which when executed after theinstructions for receiving the card account transaction information forthe merchant, cause the processor of the merchant payment servicescomputer to: apply a merchant discount rate (MDR) to the card accounttransaction information; and calculate, after application of the MDR,the merchant's net position.
 14. The integrated payment card system ofclaim 13, wherein the instructions for calculating the merchant's netposition further comprises processor executable instructions which whenexecuted cause the processor to include an amount equal to currentcharge-back transactions.
 15. The integrated payment card system ofclaim 9 wherein the storage device of the merchant payment servicescomputer stores further processor executable instructions which whenexecuted cause the processor of the merchant payment services computerto: determine, based on the net position of the merchant, that themerchant owes money to an acquirer financial institution; transmit amessage to a merchant device indicating a negative balance vis a vis theacquirer financial institution; receive, from the merchant device, arequest to transfer funds to the acquirer financial institution in anamount to satisfy the negative balance; and initiate an EFT with theoriginating PSP computer of the electronic funds transfer system tocredit an acquirer account of the acquirer financial institution in theamount to satisfy the negative balance.
 16. The integrated payment cardsystem of claim 9 wherein the EFT comprises an automated clearing house(ACH) system.